微服務作為現代組織事實上的軟件架構風格的興起以及云原生應用程序模型的快速采用為應用程序基礎架構和應用程序管理帶來了各種變化。

雖然我們在DevOps Cloud-Native Tool Landscape中簡要談到了這個主題，但本文將深入探討細節。要了解服務器網格背后的原因，我們首先需要了解云原生模型。云原生應用程序通常包含數百個微服務，并且根據服務的大小，每個服務可能會進一步泄露到數千個實例中。

當您將啟用編排的調度添加到組合中時，生成的微服務結構非常復雜，這使得服務間通信成為一個非常困難的過程。這就是服務網格的用武之地。

什么是服務網格？

簡而言之，服務網格是一個專用的基礎設施層，添加它是為了確保構成應用程序的微服務之間的通信流程簡化。作為低延遲運行的可配置基礎設施層，服務網格旨在處理應用程序基礎設施服務之間發生的越來越多的進程間通信。

隨著云原生應用模型的興起，開發者面臨著越來越多的微服務的前景。這導致越來越需要使服務間通信盡可能快速和安全。在實際世界中，服務網格的實現是通過部署大量與應用程序代碼一起工作的網絡代理（標記為“邊車”）來完成的。每個服務器實例都部署了一個 sidecar。

應用程序是否知道此類代理的部署？原則上，應用程序不需要。但是，根據部署情況，開發人員可能決定讓應用程序了解此類網絡代理。最近，組織越來越多地將服務網格作為云原生應用程序模型的重要組成部分。采用服務網格的知名組織包括 PayPal、Ticketmaster 和 Credit Karma。甚至云原生計算基金會也接受了 Linkerd——流行的開源服務網格——作為一個官方項目。這證明了服務網格在現代應用程序環境中越來越受歡迎。

服務網格作為一種網絡模型

關于服務網格是否是一種網絡模型，人們提出了各種問題。雖然服務網格絕對是一種網絡模型，但它在 TCP/IP 之上的抽象層中運行。此網絡模型與預定義的假設一起工作，即底層 L3/L4 網絡可運行并在各種服務間點之間傳送字節。這種服務網格網絡模型的另一個假設是當前網絡仍然不可靠，這意味著網格應該具備網絡故障能力。

與 TCP/IP 的相似之處

如上所述，服務網格位于 TCP/IP 層之上的抽象層，但它與通信協議共享各種特性。以下是一些相似之處：

1. TCP 堆棧的任務是抽象出在網絡端點之間可靠地傳送字節的機制。同樣，服務網格還負責抽象技術細節，以配置每個請求到相關服務的安全交付。
2. 服務網格與定義的有效負載及其加密技術無關。這是 3。就像 TCP/IP 協議具有內置的故障排除能力一樣，服務網格也旨在實現其指定的目標（例如，“將 X 從服務 1 發送到服務 2”），而不管網絡上的任何故障方法。

但是，這兩種網絡模型之間存在顯著差異，允許服務模型在 TCP/IP 協議之上運行一層。雖然后一種模型旨在完成分配的任務，但服務網格在更廣泛的范圍內運行。

除了完成分配的目標外，服務網格還負責讓開發人員增強對應用程序運行時的可見性和控制。雖然服務通信更像是一項獨立運行的后端任務，但服務網格的集成可以更有效地對其進行監控和管理。

服務網格實際上是如何工作的？

對高級通信協議的需求源于現代應用程序的復雜性。服務網格的集成不僅簡化了整個流程，還使整個團隊的工作效率更高。與每個服務器實例相連的網絡代理（邊車）負責各種功能，否則這些功能將由每個微服務自行完成。這些功能包括服務間通信和監控任何與安全相關的活動。

這允許明確區??分應用程序的管理方式，因為開發人員現在可以只關注應用程序代碼管理，這涉及開發、支持和維護。另一方面，運維團隊可以有效管理服務網格和應用運行服務。現代服務網格，例如開源Linkerd，通過利用各種先進技術來處理這些問題。

其中一些技術包括：

• 熔斷
• 負載平衡（考慮延遲要求）
• 始終可用的服務發現
• 截止日期和重試

服務網格的任務是利用這些特性，并確保它們與它們運行的??復雜環境協同工作。

有關服務網格如何工作的分步指南

為了詳細說明服務網格的運行方式，我們將使用一個示例場景。對于此實例，我們將介紹服務網格 (Linkerd) 收到請求后發生的事件：

步驟 1

收到請求后，服務網格的任務是確定服務應指向何處。有各種各樣的問題需要回答：

• 所需服務是在生產階段還是在登臺階段？
• 服務位于本地數據中心還是云端？
• 請求是指仍在測試中的微服務版本還是已經測試并部署到生產環境中的版本？

這種分層決策能力允許服務網格定位到正確的目的地。此外，所有這些路由協議都是可配置的，并且可以應用于兩種類型的流量——全局流量和任意流量。

步驟 2

一旦找到所需微服務的確切目的地，服務網格必須檢索與來自發現端點的請求中概述的詳細信息相對應的服務器實例。如果檢索到的數據與服務網格在實踐中通常監控的數據相反，它將立即決定信任哪個信息源。

步驟 3

最終實例是根據他們的反應速度來選擇的。服務網格如何衡量這一點？它監控觀察到的最近請求的延遲，然后選擇花費最少時間的實例。然后，服務網格將請求發送到實例，如果成功執行，則記錄結果結果的延遲和響應類型。

步驟 4

有時，服務器實例可能會出現故障，從而阻礙請求的成功執行。這可能是由于某個實例發生故障、變得無響應或因維護而停機。在這種情況下，服務網格會在另一個實例上重試請求。然而，這種做法的唯一問題是，如果請求是冪等的，服務網格只會用另一個實例重試。冪等請求導致相同的結果，無論它們在哪個服務實例中執行。

步驟 5

一旦請求成功執行，現代服務網格允許記錄和觀察關鍵指標。他們分析這種行為的每一個細節，并以度量和分布式跟蹤的形式記錄下來——然后傳輸到一個集中的度量系統。

那不是全部

還記得我告訴過你服務網格具有高級故障排除能力嗎？如果一個服務器實例不斷返回錯誤，那么服務網格不會簡單地忽略該實例。服務網格將這樣的服務器實例從整個負載均衡池中移除。這允許轉換資源并提高效率。

這是另一個展示現代服務網格功效的示例。當一個請求由于截止日期而過去時，服務網格會識別此類請求并自動使請求失敗。服務網格不會繼續重試失敗的請求并增加網絡負載，而是確保資源的有效分配。除了其他功能外，服務網格還可以執行協議升級、動態切換流量以及在其他服務中啟動和終止 TLS。

服務網格提供的好處

使用服務網格作為抽象層有多種好處。這里是其中的一些：

提高標準化

隨著現代應用程序繼續分布在一個龐大的基礎上，它們的功能行為也變得極其不穩定——這取決于底層支持網絡。由于跨不同網絡的這種不同行為，確保應用程序的全天候可用性可能成為一項嚴峻的挑戰。使用服務網格，網格可以處理應用程序的旋轉、折疊和分割。它使數據中心更加標準化和組織化。

增強可見性

高級服務網格分析請求行為以確定請求最多的組件，以便可以定位它們以便于訪問。再加上它的問題排查能力，它對整個系統有一個全面的概覽。如前所述，服務網格可以存儲此數據以供進一步使用。開發人員可以使用這些數據來識別趨勢和威脅，從而改進整個開發和構建過程。

高級安全

與單體軟件架構相反，微服務軟件由不同種類的服務組成。有些可能有很長的壽命，而另一些的生命周期很短。這使得唯一身份的分配和工作政策的執行變得越來越復雜。

相反，開發人員可以使用服務網格在所有實時實例和所有可操作的微服務上實施相關策略。由于它能夠識別正在運行的微服務及其運行位置，因此它可以根據微服務的類型和行為應用策略。這不僅消除了為每個服務或實例分配唯一 ID 的需要，而且還允許開發人員無誤地執行策略。

主要服務網格工具

有多種服務網格工具可供開發人員使用。然而，與云原生應用程序的其他方面不同，該領域可用的工具大多是開源項目。在服務網格方面，沒有現成的商業工具。

以下是最受歡迎的列表：

Linkerd

發音為“linker-dee”，這是所有服務網格中最古老的，于 2016 年發布。它基本上是從 Twitter 開發的庫設計的衍生項目開始的。還有另一個服務網格，Conduit，它獲得了廣泛的普及。然而，它在 2017 年被整合到 Linkerd 程序中，并在 Linked 2.0 的創建中發揮了重要作用。

Envoy

Envoy 是另一個服務網格，它的起源可以追溯到一個著名的組織。在這種情況下，它是 Lyft。特使針對服務網格的“數據計劃”部分。為了提供完整的功能，它需要與“控制平面”服務網格結合使用。

Istio

為了讓像 Envoy 這樣的“數據平面”服務網格平臺正常工作，組織需要一個“控制平面”服務網格。這就是 Istio 應運而生的原因。作為 IBM、谷歌和 Lyft 之間的協作成果——Istio 和 Envoy 成對運行，在兩個服務網格組件之間提供完整的平臺內可行性。

HashiCorp顧問

HashiCorp 本質上作為一個用于服務發現和配置的分布式系統運行。然而，隨著 Consul 1.2 的發布，他們引入了一個名為 Connect 的功能，該功能允許服務加密和基于身份的授權。這將它變成了一個完整的服務網格產品。

結論

隨著開發人員繼續應對管理微服務帶來的復雜性，服務網格將繼續在云原生應用程序生態系統中得到更多采用。隨著利用服務網格的用戶和開發人員社區蓬勃發展，全球各地的組織已經開始將服務網格集成到他們的軟件架構設計中。隨著計算的不斷發展，服務網格在應用程序環境中的范圍也將發生變化。